The Internet has changed society and is as much a part of modern culture as television and telephones. People are becoming increasingly connected to share and access information. This interconnectivity promotes improvements in the computing and communication infrastructure.
Much of this infrastructure was designed for entertainment or communication, but is being adapted to deliver general data. The addition of general information and data transmission over the legacy infrastructure has necessarily been somewhat restrained by the need for the infrastructure to continue its initial functions. Furthermore, legacy technical characteristics of this infrastructure influence the various solutions to include information storage and transmission. Most major entertainment and communication channels now include computer networking capabilities.
Many people get their television service through cable television (CATV). CATV was initially developed to deliver television signals to areas where antennas had difficulty picking up television broadcasts. Coaxial cabling is the primary type of cabling used by the cable television industry because it is much less susceptible to interference and can carry large amounts of data.
Television signals are broadcast in 6 MHz channels and this channel bandwidth was incorporated into cable television. As transmission demands increased, parts of the coaxial backbone were replaced with optical fiber to create a hybrid fiber-coaxial (HFC) network. The bandwidth of the cable infrastructure makes it an attractive technology to incorporate data transmission.
An example use of data over a cable television network was approved by the International Telecommunications Union (ITU) which includes interface requirements for high speed data communication, and is called the data over cable service interface specification (DOCSIS).
Cable service providers also offer internet service through the cable television network in 6 MHz channels for downstream data. Upstream data has historically received less bandwidth and has been offered in a fraction of a channel, such as in 2 MHz provisions. This asymmetry was due to the Internet initially being an information provider. Currently, peer-to-peer computing, file sharing, gaming, and other uses have increased the need for upstream bandwidth.
Due to the legacy CATV infrastructure primarily being a broadcast channel, there are different modulation schemes for upstream and downstream transmission, for example, downstream utilize 64 and 256 Quadrature Amplitude Modulation (QAM) and upstream utilizes Quadrature Phase Shift Keying or 16 QAM.
Furthermore, to allow maximum data transmission through different networks, DOCSIS supports use of various combinations of modulation and therefore different data rates, which in turn complicates the physical layer in these networks.
Placing upstream and downstream data onto the cable television network requires special equipment at each end of the HFC plant. On the customer end, a cable modulator/demodulator (cable modem, or CM) transmits and receives data over the cable television infrastructure and on the cable provider end a cable modem termination system (CMTS) is used to place and retrieve data from the cable television network.
Typically a CMTS broadcasts to numerous CMs over a shared channel while each CM separately sends upstream data. In this framework, a cable modem must select only the broadcast downstream data that is intended for it while it must follow an arbitration protocol to avoid data collisions with other cable modems while transmitting upstream data.
A CMTS may also multicast data. Multicast is based on the concept of a group where an arbitrary group of receivers can each receive a particular data stream. Hosts that are interested in receiving data flowing to a particular group join the group using Internet Group Management Protocol (IGMP). Hosts must be a member of the group to receive the data stream. Multicasting conserves bandwidth by simultaneously delivering a single stream of information to multiple recipients.
CMTS multicasting may be accomplished using a multicast internet protocol (IP) address. The current version of IP (IPv4) uses a 32-bit addressing scheme, often represented by 4 numbers separated by periods such as 198.133.219.25.
IP Multicast delivers source traffic to multiple receivers without adding additional burdens on the source or the receivers while limiting network bandwidth consumption. Multicast routing establishes a tree that connects a source with receivers. Multicast delivery sends data across this tree towards receivers. Data is not copied at the source, but rather, inside the network at distribution branch points. Only a single copy of data is sent over links that lead to multiple receivers, resulting in bandwidth gains.
For example, multicast packets may be replicated in a network by a router enabled with Protocol Independent Multicast (PIM) and other supporting multicast protocols. Unlike broadcast, the traffic is only received and processed by devices that are listening for it. Videoconferencing, stock quotes, news, distance learning, and distribution of software, etc., are example applications that benefit from multicasting.
DOCSIS 2.0 defines several hooks for enabling multicast over the radio frequency (RF) portion of a cable network. IGMP snooping in a CM can be used to trigger a Baseline Privacy Interface (BPI) exchange for a multicast session. IGMP snooping restrains multicast traffic and specifies how a host can register a router to receive specific multicast traffic. BPI extensions can be used to provide encryption of multicast sessions.
In conventional DOCSIS, a user at an end device may want to join a certain multicast session. For example, the device may present a web page with a channel descriptor to the user and the user can select which channel they want to view or which multicast session they want to attend. The channel descriptor may associate that channel or session with the destination IP address used in the actual multicast. To receive the multicast session or channel, the end device may send an IGMP join message to a CMTS or other server asking to join the multicast group.
In DOCSIS 2.0, a CM snoops these IGMP join messages, and when it sees an end device wants to receive a certain channel or multicast session, the CM maps a multicast address to a MAC address using RFC 1112 mapping, and uses that MAC address to set an Ethernet filter to restrain multicast traffic.
Additionally, when the CM snoops the IGMP join and gets the MAC address for the filter, the CM may negotiate a key exchange with an associated CMTS in order to decrypt the desired multicast session and forward it to the end device. Unfortunately, this conventional approach for enabling multicast traffic over a cable network does not address many multicast issues.
The current multicasting scheme allows for aliasing of traffic. According to the request for comments (RFC) 1112, aliasing of traffic may happen because only the lower order 23 bits of an IP address are mapped to a multicast Ethernet media access control (MAC) address.
A MAC address is a layer 2 unique identifier attached to most forms of networking equipment. MAC addresses may be mapped to a layer 3 protocol address and back, for example, by an address resolution protocol (ARP) or a reverse ARP (RARP). Unfortunately this can result in aliasing when the lower order 23 bits of an IP address are the same, for example, a CM configured to receive traffic for group 224.1.2.3 will also accept traffic for 239.1.2.3.
Aliasing is particularly an issue with virtual private network (VPN) and source-specific multicast (SSM) support. For VPNs, two separate networks might have the same addressing scheme, and therefore the same Ethernet MAC address. For SSM, two multicast groups might differ only by a source address, since Ethernet MAC mapping takes only the destination into account, this may also result in aliasing.
DOCSIS 2.0 also provides only limited support for multicast protocols. It does not have IGMP snooping support for IGMPv3 and SSM, Generic Attribute Registration Protocol (GARP), GARP Multicast Registration Protocol (GMRP) or Multicast Listener Discovery (MLD). This discrepancy is in large part due to the different length headers and different representations in each of the headers. This will continue to be a problem as new versions of these protocols likely will generate additional changes in their headers and therefore complicate snooping of these protocols to establish multicast sessions.
DOCSIS 2.0 leaves many other multicast issues unaddressed. One area left unaddressed is support for IP Version 6 (IPv6) since IPv6 has a dedicated control plane for multicast. Additionally, PacketCable Multimedia (PCMM) does not yet define how multicast is to be supported, and there are no appropriate hooks in DOCSIS 2.0 to support it.
Another area is limited monitoring at a CMTS. For example, IGMP v1/v2 reports may be suppressed and subsequently, it is not possible to obtain a list of CMs that joined a multicast session.
Quality of Service (QoS) is also not addressed for multicast flows under conventional DOCSIS. Multicast flows can be thought of as unidirectional flows, and in that respect, they are supported by DOCSIS specifications. However, the details on how QoS is assigned to multicast flows are not defined because unlike other DOCSIS flows they are not owned by a single modem.
Another multicast area left unaddressed by conventional DOCSIS is in routed networks on the customer premises equipment (CPE) side. The network cannot easily support routers connected in the CPE network that run Protocol Independent Multicast (PIM) instead of IGMP. Additionally, in conventional DOCSIS there is no way for either a CM or CMTS to make sure a multicast session is successfully activated since there is no explicit acknowledgment in IGMPv2.
Support for multicast in current cable networks is limited in scope in at least the areas explained above. What is needed is a new multicast approach in cable networks.